<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <LINK href="enzo.css" rel="stylesheet" type="text/css">
    <title>ENZO parameter list (sorted)</title>
  </head>

  <body>
    <h1>ENZO parameter list (sorted)</h1>

    <p>
      The following is a largely complete list of the parameters that
      enzo understands, and a brief description of what they mean.
      This is a sorted version of the original <A
      HREF="parameters.html"> parameters list</A>.  Parameters for
      individual test problems are not listed here.
    </p>

    <p>
      This parameter list has two purposes.  The first is to describe
      and explain the parameters that can be put into the initial
      parameter file that begins a run.  The second is to provide a
      comprehensive list of all parameters that the code uses,
      including those that go into an output file (which contains a
      complete list of all parameters), so that users can better
      understand these output files.
    </P>

    <p>The parameters fall into a number of categories:</P>

    <ol>
      <li><p>
	  <b class="external">external</b> - These are user parameters in the sense that they can be set
	  in the parameter file, and provide the primary means of communication between
	  the enzo and the user.</p></li>

      <li><p>
	  <b class="internal">internal</b> - These are mostly not set in the parameter file (although strictly
	  speaking they can be) and are generally used for program to communicate
	  with itself (via the restart of output files).</p></li>

      <li><p>
	  <b class="obsolete">obsolete</b></p></li>

      <li><p>
	  <b class="reserved">reserved</b></p></li>
    </ol>

    <P>Generally the external parameters are the only ones that are
      modified or set, but the internal parameters can provide useful
      information and can sometimes be modified so I list them here as
      well.  Some parameters are true/false or on/off boolean
      flags.  Eventually, these may be parsed, but in the meantime,
      I use the common convention of 0 meaning false or off and 1 for
      true or on.</P>

    <p>This list include parameters for both v1.2 and  v1.3
      (which is an MPI verson, and now the main development
      platform). Since these two versions use some different algorithms
      as well, some parameters have been added, modified or are
      ignored. This is noted in the test where appropriate.</P>

    <ul>
      <li><p><b class="external">BaryonSelfGravityApproximation</b> (external) - Flag
	  indicate if baryon density is derived in a strange, expensive
	  but self-consistent way (0 - off), or by a completely reasonable
	  and much faster approximation (1 - on).  This is an experiment
	  gone wrong; leave on. Well, actually, it's important for very
	  dense structures as when radiative cooling is turned on, so set
	  to 0 if using many levels and radiative cooling is on [ignored
	  in version 1.3].  Default: 1</p></li>

      <li><p><b class="external">BoundaryConditionName</b> (external) - While the above
	  parameters provide an easy way to set an entire side of grid to
	  a given boundary value, the possibility exists to set the
	  boundary conditions on an individual cell basis.  This is most
	  often done with problem specify code, but it can also be set by
	  specifying a file which contains the information in the
	  appropriate format.  This is too involved to go into here.
	  Default: none</p></li>

      <li><p><b class="external">CellFlaggingMethod </b>(external) - The method(s) used to
	  specify when a cell should be refined. This is a list of integers,
	  up to five, as described by the following table. The methods
	  combine in an "OR" fashion: if any of them indicate that a cell
	  should be refined, then it is.  For cosmology simulations, methods
	  2 and 4 are probably most useful.  Note that some method have
	  additional parameters which are described below.  Default: 1

	<center><table>
	      <tr>
		<td>1 - refine by slope</td>
		<td>5 - refine by baryon overdensity (currently disabled)</td>
	      </tr>
	      <tr>
		<td>2 - refine by baryon mass</td>
		<td>6 - refine by Jeans length </td>
	      </tr>
	      <tr>
		<td>3 - refine by shocks</td>
		<td>7 - refine if cooling time &lt; cell width/sound speed</td>
	      </tr>
	      <tr>
		<td>4 - refine by particle mass</td>
                <td> </td>
	      </tr>
	  </table></center>
      </li>
      
      <li><p> <b class="external">ComovingCoordinates</b> (external) -
	  Flag (1 - on, 0 - off) that determines if comoving coordinates
	  are used or not.  In practice this turns on or off the entire
	  cosmology machinery.  Default: 0</p></li>

      <li><p><b class="external">ComputePotential</b> (external) -
	  This flag (1 -on, 0 - off) indicates if the gravitational
	  potential is to be computed on the mesh.  This is necessary if
	  the energy conservation is to be computed.  [not tested in
	  version 1.3] Default: 0</p></li>

      <li><p><b class="external">ConservativeInterpolation</b> (external) - This flag (1 -
	  on, 0 - off) indicates if the interpolation should be done in
	  the conserved quantities (e.g. momentum rather than velocity).
	  Ideally, this should be done, but it can cause problems when
	  strong density gradients occur.  This must(!) be set off for
	  ZEUS hydro. Default: 1</p></li>

      <li><p><b class="external">CosmologyComovingBoxSize</b> (external) - The size of the
	  volume to be simulated in Mpc/h (at z=0). Default: 64.0</p></li>

      <li><p><b class="external">CosmologyCurrentRedshift</b> (information only) - This is
	  not strictly speaking a parameter since it is never interpreted
	  and is only meant to provide information to the user.  Default:
	  n/a</p></li>

      <li><p><b class="external">CosmologyHubbleConstantNow</b> (external) - The Hubble
	  constant at z=0, in units of 100 km/s/Mpc. Default: 0.5</p></li>

      <li><p><b class="external">CosmologyInitialRedshift</b> (external) - The redshift
	  for which the initial conditions are to be generated. Default:
	  20.0</p></li>

      <li><p><b class="external">CosmologyMaxExpansionRate</b> (external) - This float
	  controls the timestep so that cosmological terms are accurate
	  followed.  The timestep is constrained so that the relative
	  change in the expansion factor in a step is less than this
	  value.  Default: 0.01</p></li>

      <li><p><b class="external">CosmologyOmegaLambdaNow</b> (external) - This is the
	  contribution of the cosmological constant to the energy density
	  at the current epoch, in the same units as above. Default: 0.0</p></li>

      <li><p><b class="external">CosmologyOmegaMatterNow</b> (external) - This is the
	  contribution of all non-relativistic matter (including HDM) to
	  the energy density at the current epoch (z=0), relative to the
	  value required to marginally close the universe. It includes
	  dark and baryonic matter. Default: 1.0</p></li>

      <li><p><b class="external">CosmologyOutputRedshift[####]</b> (external) - The time
	  and cycle-based outputs occur regularly at constant intervals,
	  but the redshift outputs are specified individually.  This is
	  done by the use of this statement, which sets the output
	  redshift for a specific identification number (this integer is
	  between 0000 and 9999 and is used in forming the name).  So the
	  statement CosmologyOutputRedshift[1] = 4.0 will cause an output
	  to be written out at z=4 with the name RedshiftOutput0001
	  (unless the base name is changed either with the previous
	  parameter or the next one).  This parameter can be repeated with
	  different values for the number (####).  Default: none</p></li>

      <li><p><b class="external">CosmologyOutputRedshiftName[####]</b> (external) - This
	  parameter overrides the parameter RedshiftOutputName for this
	  (only only this) redshift output.  Can be used repeatedly in the
	  same manner as the previous parameter.  Default: none</p></li>

      <li><p><b class="external">CourantSafetyNumber</b> (external) - This is the maximum
	  fraction of the CFL-implied timestep that will be used to
	  advance any grid.  A value greater than 1 is unstable (for all
	  explicit methods).  The recommended value is 0.4.  Default:
	  0.6.</p></li>

      <li><p><b class="internal">CycleLastDataDump</b> (internal) - The cycle number at
	  which the last cycle-based output occurred.</p></li>

      <li><p><b class="reserved">CycleLastHistoryDump</b> - Reserved for future use.</p></li>

      <li><p><b class="reserved">CycleLastRestartDump</b> - Reserved for future use.</p></li>

      <li><p><b class="external">CycleSkipDataDump</b> (external) - The number of cycles
	  (top grid timesteps) between cycle-based outputs.  Zero turns
	  off the cycle-based outputs.  Default: 0</p></li>

      <li><p><b class="reserved">CycleSkipHistoryDump</b> - Reserved for future use.</p></li>

      <li><p><b class="reserved">CycleSkipRestartDump</b> - Reserved for future use.</p></li>

      <li><p><b class="external">DataDumpName </b>(external) - The base file name used for
	  both time and cycle based outputs.  Default: <i>data</i></p></li>

      <li><p><b class="internal">DataDumpNumber</b> (internal) - The identification number
	  of the next output file (the 0000 part of the output name).
	  This is used and incremented by both the cycle based and time
	  based outputs.  Default: 0</p></li>

      <li><p><b class="external">DomainLeftEdge, DomainRightEdge</b> (external) - These
	  float values specify the two corners of the problem domain (in
	  code units).  The defaults are: 0 0 0 for the left edge and
	  1 1 1 for the right edge.</p></li>

      <li><p><b class="external">dtDataDump </b>(external) - The time interval, in code
	  units, between time-based outputs.  A value of 0 turns off the
	  time-based outputs.  Default: 0</p></li>

      <li><p><b class="reserved">dtHistoryDump</b> - Reserved for future use.</p></li>

      <li><p><b class="external">dtMovieDump </b>(external) - The time interval, in
	  code units, between movie dumps.  A value of 0 turns off the
	  movie dumps.  Default: 0</p></li>

      <li><p><b class="reserved">dtRestartDump</b> - Reserved for future use.</p></li>

      <li><p><b class="external">DualEnergyFormalism</b> (external) - The dual energy
	  formalism is need to make total energy schemes such as PPM DE
	  and PPM LR stable and accurate in the "hyper-Machian" regime
	  (i.e. where the ratio of thermal energy to total energy &lt;
	  ~0.001).  Turn on for cosmology runs with PPM DE and PPM LR.
	  Automagically turned off when used with the hydro method ZEUS.
	  Integer flag (0 - off, 1 - on).  When turned on, there are two
	  energy fields: total energy and thermal energy.  Default: 0</p></li>

      <li><p><b class="external">DualEnergyFormalismEta1, DualEnergyFormalismEta2</b>
	  (external) - These two parameters are part of the dual energy
	  formalism and should probably not be changed.  Defaults: 0.001
	  and 0.1 respectively.</p></li>

      <li><p><b class="external">FluxCorrection</b> (external) - This flag indicates if
	  the flux fix-up step should be carried out around the boundaries
	  of the sub-grid to preserve conservation (1 - on, 0 - off).
	  Strictly speaking this should always be used, but I have found
	  it to lead to a less accurate solution for cosmological
	  simulations because of the relatively sharp density gradients
	  involved.  However, it does appear to be important when
	  radiative cooling is turned on and very dense structures are
	  created (this note added sheepishly in April/99). It does work
	  with the ZEUS hydro method, but since velocity is face-centered,
	  momentum flux is not corrected.  Species quantities are not flux
	  corrected directly but are modified to keep the fraction
	  constant based on the density change.  Default: 1</p></li>

      <li><p><b class="external">Gamma</b> (external) - The ratio of specific heats for an
	  ideal gas (used by all hydro methods).  If using multiple
	  species (i.e. MultiSpecies > 0), then this value is ignored in
	  favour of a direct calculation (except for PPM LR) Default:
	  5/3.</p></li>

      <li><p><b class="external">GravitationalConstant</b> (external) - This is the
	  gravitational constant to be used.  For cgs units it should be
	  4*pi*G.  For cosmology, this value must be 1 for the standard
	  units to hold.  Default: 4*pi.</p></li>

      <li><p><b class="external">GravityResolution</b> (external) - This was a mis-guided
	  attempt to provide the capability to increase the resolution of
	  the gravitational mesh.  In theory is still works, but has not
	  been recently tested.  Besides, it's just not a good idea.  The
	  value (a float) indicates the ratio of the gravitational cell
	  width to the baryon cell width. [Ignored in version 1.3].
	  Default: 1</p></li>

      <li><p><b class="external">GreensFunctionMaxNumber</b> (external) - The Green's
	  functions for the gravitational potential depend on the grid
	  size, so they are calculated on a as-needed basis.  Since they
	  are often re-used, they can be cached.  This integer indicates
	  the number that can be stored.  They don't take much memory
	  (only the real part is stored), so a reasonable number is
	  100. [Ignored in version 1.3 - amr_mpi]. Default: 1</p></li>

      <li><p><b class="external">GreensFunctionMaxSize</b> (reserved) - Reserved for future use.</p></li>

      <li><p><b class="obsolete">GridVelocity</b> (obsolete) - For problems in which the
	  grid must move.  Originally implemented, but was never used, and
	  so almost surely doesn't work.  Default: 0 0 0</P>

	<p>There are three ways to specify the frequency of outputs:
	  time-based, cycle-based (a cycle is a top-grid timestep), and,
	  for cosmology simulations, redshift-based.  There is also a
	  shortened output format intended for visualization (<a
								 href="output.html#movie dumps">movie format</a>).</P></li>

      <li><p><b class="reserved">HistoryDumpName</b> - Reserved for future use.</p></li>

      <li><p><b class="reserved">HistoryDumpNumber</b> - Reserved for future use.</p></li>

      <li><p><b class="external">huge_number </b>(external) - The largest reasonable
	  number.  Rarely used.  Default: 1e+20.</p></li>

      <li><p><b class="external">HydroMethod</b> (external) - This integer specified the
	  hydrodynamics method that will be used.  Currently implemented
	  are: 0 - PPM DE (a direct-Eulerian version of PPM), 1 - PPM LR
	  (a Lagrange-Remap version of PPM), 2 - ZEUS (a Cartesion, 3D
	  version of Stone &amp; Norman).  The PPM LR version is not
	  recommended.  Note that if ZEUS is selected, it automatically
	  turns off ConservativeInterpolation and the DualEnergyFormalism
	  flags.  Default: 0</p></li>

      <li><p><b class="reserved">InitialCPUTime</b> - Reserved for future use.</p></li>

      <li><p><b class="internal">InitialCycleNumber</b> (internal)- One cycle is one
	  topgrid timestep.  This is the cycle number of the current step.
	  Default: 0</p></li>

      <li><p><b class="internal">InitialTime</b> (internal) - The time, in "code" units,
	  of the current step.  For cosmology the units are in free-fall
	  times at the initial epoch (see <a href="output.html">output</a>
	  format).  Default: generally 0, depends on problem</p></li>

      <li><p><b class="external">InterpolationMethod</b> (external) - There should be a
	  whole section devoted to the interpolation method, which is used
	  to generate new sub-grids and to fill in the boundary zones of
	  old sub-grids, but a brief summary must suffice.  The possible
	  values of this integer flag are shown in the table below.  The
	  names specify (in at least a rough sense) the order of the
	  leading error term for a spatial Taylor expansion, as well as a
	  letter for possible variants within that order.  The basic
	  problem is that you would like your interpolation method to be:
	  multi-dimensional, accurate, monotonic and conservative.  There
	  doesn't appear to be much literature on this, so I've had to
	  experiment.  The first one (ThirdOrderA) is time-consuming and
	  probably not all that accurate.  The second one (SecondOrderA)
	  is the workhorse: it's only problem is that it's not always
	  symmetric.  The nbext one (SecondOrderB) is a failed experiment,
	  and SecondOrderC is not conservative.  FirstOrderA is everything
	  except for accurate.  If HydroMethod = 2 (ZEUS), this flag is
	  ignored, and the code automatically uses SecondOrderC for
	  velocities and FirstOrderA for cell-centered quantities.
	  Default: 1<P>

	<center><table>
	      <tr>
		<td>0 - ThirdOrderA</td>
		<td>3 - SecondOrderC</td>
	      </tr>
	      <tr>
		<td>1 - SecondOrderA</td>
		<td>4 - FirstOrderA</td>
	      </tr>
	      <tr>
		<td>2 - SecondOrderB</td>
		<td> </td>
	      </tr>
	  </table></center></li>

      <li><p><b class="external">LeftFaceBoundaryCondition, RightFaceBoundaryCondition</b>
	  (external) - These two parameters each consist of vectors of
	  integers (of length TopGridRank).  They specify the boundary
	  conditions for the top grid (and hence the entire hierarchy).
	  The first integer corresponds to the x-direction, the second to
	  the y-direction and the third, the z-direction.  The possible
	  values are: 0 - reflecting, 1 - outflow, 2 - inflow, 3 -
	  periodic.  For inflow, the inflow values can be set through the
	  next parameter, or more commonly are controlled by
	  problem-specific code triggered by the ProblemType.  Default: 0
	  0 0</p></li>

      <li><p><b class="external">MaximumGravityRefinementLevel</b> (external) - This is
	  the lowest (most refined) depth that a gravitational
	  acceleration field is computed. More refined levels interpolate
	  from this level, provided a mechanism for insituting a minimum
	  gravitational smoothing length. Default: MaximumRefinetLevel
	  (unless HydroMethod is zeus and radiative cooling is on, in
	  which case it is MaximumRefinementLevel - 3).</p></li>

      <li><p><b class="external">MaximumParticleRefinementLevel</b> (exernal) - This is
	  the level at which the dark matter particle contribution to the
	  gravity are smoothed.  This works in an inefficient way (it
	  actually smoothes the particle density onto the grid), and so is
	  only intended for highly refined regions which are nearly
	  completely baryon dominated.  It is used to remove the
	  discreteness effects of the few remaining dark matter particles.
	  Not used if set to a value less than 0. [Only valid for version
	  1.3]. Default: -1</p></li>

      <li><p><b class="external">MaximumRefinementLevel</b> (external) - This is the
	  lowest (most refined) depth that the code will produce.  It is
	  zero based, so the total number of levels (including the root
	  grid) is one more than this value.  Default: 2</p></li>

      <li><p><b class="external">MinimumEfficiency</b> (external) - When new grids are
	  created during the rebuilding process, each grid is split up by
	  a recursive bisection process that continues until a subgrid is
	  either of a minimum size or has an efficiency higher than this
	  value.  The efficiency is the ratio of flagged zones (those
	  requiring refinement) to the total number of zones in the grid.
	  This is a number between 0 and 1 and should probably by around
	  0.4 for standard three-dimensional runs.  Default: 0.2</p></li>

      <li><p><b class="external">MinimumEnergyRatioForRefinement</b> (external) - For the
	  dual energy formalism, and cell flagging by shock-detection, this
	  is an extra filter which removes weak shocks (or noise in the dual
	  energy fields) from triggering the shock detection.  Default:
	  0.1</p></li>

      <li><p><b class="internal">MinimumMassForRefinement</b> (internal) - This float is
	  usually set by the parameter above and so is labeled internal, but
	  it can be set by hand.  It is the mass (in units such that the
	  entire mass in the computational volume is 1.0) above which a
	  refinement occurs if the CellFlaggingMethod is appropriately
	  set. There are five numbers here again, as per the above
	  parameter.  Default: none</p></li>

      <li><p><b class="external">MinimumMassForRefinementLevelExponent</b> (external).  This
	  parameter modifies the behaviour of the above parameter.  As it
	  stands, the refinement based on the MinimumMassForRefinement
	  (hereafter Mmin)parameter is complete Lagrangian.  However, this
	  can be modified.  The actual mass used is Mmin*r^(l*alpha) where r
	  is the refinement factor, l is the leve and alpha is the value of
	  this parameter (MinimumMassForRefinementLevelExponent).  Therefore
	  a negative value makes the refinement super-Lagrangian, while
	  positive values are sub-Lagrangian. There are up to five values
	  specified here, as per the above two parameters.  Default:
	  0.0</p></li>

      <li><p><b class="external">MinimumOverDensityForRefinment</b> (external) - These
	  float values (up to 5) are used if the CellFlaggingMethod is 2,
	  4, or 5 although in slightly different ways.  For Method 5, this
	  is the overdensity in terms of (rho/&lt;rho> - 1), where rho is
	  the density of the cell, and &lt;rho> is the mean density.  For
	  the others, the meaning is actually just rho/&lt;rho> where rho
	  is the density of the appropriate species.  This value is
	  converted into a mass, by multiplying by the volume of the a top
	  grid cell.  This result is then stored in the next parameter
	  (unless it is set directly in which case this parameter is
	  ignored), and this defines the mass resolution of the
	  simulation.  Note that the volume is of a top grid cell, so if
	  you are doing a multi-grid initialization, you must divide this
	  number by r^(d*l) where r is the refinement factor, d is the
	  dimensionality and l is the (zero-based) lowest level.  For
	  example, for a two grid setup where a cell should be refined
	  whenever the mass exceeds 4 times the mean density of the
	  subgrid, this value should be 4 / (2^(3*1)) = 4 / 8 = 0.5.  Keep
	  in mind that this parameter has no effect if it is changed in a
	  restart output; if you want to change the refinement mid-run you
	  will have to modify the next parameter.  Up to five numbers may
	  be specified here, each corresponding to the respective
	  CellFlaggingMethod. Default: 1.5</p></li>

      <li><p><b class="external">MinimumPressureJumpForRefinement</b> (external) - If
	  refinement is done by shocks, then this is the minimum (relative)
	  pressure jump in one-dimension to qualify for a shock.  The
	  definition is rather standard (see Colella and Woodward's PPM
	  paper for example) Default: 0.33</p></li>

      <li><p><b class="external">MinimumPressureSupportParameter</b> (external) - This is
	  the parameter alluded to above. Very roughly speaking, is is the
	  number of cells over which a gravitationally bound small cold
	  clump, on the most refined level, will be spread over. [v1.3
	  only] Default: 100</p></li>

      <li><p><b class="external">MinimumSlopeForRefinement</b> (external) - If
	  CellFlaggingMethod is 1, then local gradients are used as the
	  refinement criteria.  All variables are examined and the relative
	  slope is computed: abs(q(i+1)-q(i-1))/q(i).  Where this value
	  exceeds this parameter, the cell is marked for refinement.  This
	  causes problems if q(i) is near zero. This is a single integer (as
	  opposed to the list of five for the above parameters).  Default:
	  0.3</p></li>

      <li><p><b class="external">MovieDumpName</b> (external) - This character parameter
	  is the base name of the movie dumps.  Default: MovieData</p></li>

      <li><p><b class="internal">MovieDumpNumber</b> (internal) - The identification
	  number of the next movie output file.  Default: 0</p></li>

      <li><p><b class="external">MovieRegionLeftEdge, MovieRegionRightEdge</b> (external)
	  - This two parameters control the region for which movie dumps
	  are made.  When a movie dump is generated (see the section on
	  output format), only those grid points and particles within this
	  region are written out to the movie data files.</p></li>

      <li><p><b class="external">MultiSpecies</b> (external) - If this flag (1, 2, 3- on,
	  0 - off) is on, then the code follows not just the total
	  density, but also the ionization states of Hydrogen and Helium.
	  If set to 2, then a nine-species model (including H2, H2+ and
	  H-) will be computed, otherwise only six species are followed
	  (H, H+, He, He+, He++, e-). If set to 3, then a 12 species model
	  is followed, including D, D+ and HD [Deuterium is currently
	  broken].  This routine, like the last one, is based on work done
	  by Abel, Zhang and Anninos.  Default: 0</p></li>

      <li><p><b class="external">NumberOfBufferZones</b> (external) - Each flagged cell,
	  during the regridding process, is surrounded by a number of
	  zones to prevent the phenomenon of interest from leaving the
	  refined region before the next regrid.  This integer parameter
	  controls the number required, which should almost always be one.
	  Default: 1 </p></li>

      <li><p> <b class="obsolete">NumberOfParticles </b>(obsolete) - Currently ignored by
	  all initializers, except for TestGravity and TestGravitySphere
	  where it is the number of test points.  Default: 0</p></li>

      <li><p><b class="external">ParallelRootGridIO</b> (external) - Normally, for the mpi
	  version, the root grid is read into the root processor and then
	  partition to separate processors.  However, for very large root
	  grids (e.g. 512^3), the root processor may not have enough
	  memory.  If this toggle switch is set on (i.e. to the value 1),
	  then each processor reads its own section of the root grid.
	  More I/O is required (to split up the grids and particles), but
	  it is more balanced in terms of memory.  [v1.3 onyl].  Default:
	  0</p></li>

      <li><p> <b class="external">ParticleBoundaryType</b> (external) - The boundary
	  condition imposed on particles.  At the moment, this parameter
	  is largely ceremonial as there is only one type implemented:
	  periodic, indicated by a 0 value.  Default: 0</p></li>

      <li><p> <b class="external">ParticleCourantSafetyNumber</b> (external) - This
	  somewhat strangely named parameter is the maximum fraction of a
	  cell width that a particle is allowed to travel per timestep
	  (i.e. it is a constant on the timestep somewhat along the lines
	  of it's hydrodynamic brother).  Default: 0.5</p></li>

      <li><p> <b class="external">PointSourceGravity</b> (external) - This flag (1 - on, 0
	  - off) indicates if there is to be a (constant) point source
	  gravitational field.  Default: 0</p></li>

      <li><p> <b class="external">PointSourceGravityConstant</b> (external) - The
	  magnitude of the point source acceleration at a distance of 1
	  length unit.  Default: 1</p></li>

      <li><p> <b class="external">PointSourceGravityPosition</b> (external) - If the
	  PointSourceGravity flag is turned on, this parameter specifies
	  the center of the point-source gravitational field.  Default: 0
	  0 0</p></li>

      <li><p><b class="external">PPMDiffusionParameter </b>(external) - This is the PPM
	  diffusion parameter (see the Colella and Woodward method paper
	  for more details).  It is either on (1) or off (0).  Default:
	  1</p></li>

      <li><p><b class="external">PPMFlatteningParameter </b>(external) - This is a PPM
	  parameter to control noise for slowly-moving shocks.  It is
	  either on (1) or off (0).  Default: 0</p></li>
      
      <li><p><b class="external">PPMSteepeningParameter </b>(external) - A PPM
	  modification designed to sharpen contact discontinuities.  It is
	  either on (1) or off (0).  Default: 0</p></li>

      <li><p><b class="external">PressureFree</b> (external) - A flag that is interpreted
	  by the PPM DE hydro method as an indicator that it should try
	  and mimic a pressure-free fluid.  A flag: 1 is on, 0 is off.
	  Default: 0 </p></li>

      <li><p><b class="external">ProblemType</b> (external) - This integer
	  specifies the type of problem to be run.  It's value
	  causes the correct problem initializer to be called to set up
	  the grid, and also may trigger certain boundary conditions or
	  other problem-dependent routines to be called.  The
	  possible value are listed below.  [For version 1.3, not
	  all of these problems run with more than one processor. The
	  list of those known to work in parallel are: 23, 25, 30.]
	  Default: none<P>

      <center><table>
	  <tr>
	    <td>1 - Shock Tube</td>
	    <td>20 - Zeldovich Pancake</td>
	    <td>25 - TestGravity Sphere</td>
	  </tr>
	  <tr>
	    <td>2 - Wave Pool</td>
	    <td>21 - Pressureless Collapse</td>
	    <td>26 - Gravity Equilibrium Test</td>
	  </tr>
	  <tr>
	    <td>3 - Shock Pool</td>
	    <td>22 - Adiabatic Expansion</td>
	    <td>27 - Collapse test</td>
	  </tr>
	  <tr>
	    <td>4 - Double Mach Reflection</td>
	    <td>23 - TestGravity</td>
	    <td>30 - Cosmology Simulation</td>
	  </tr>
	  <tr>
	    <td>5 - Shock In A Box</td>
	    <td>24 - Spherical Infall</td>
	    <td>40 - Reserved</td>
	  </tr>
	</table></center>
      </li>

      <li><p><b class="external">RadiationFieldType</b> (external) - This integer
	  parameter specifies the type of radiation field that is to be
	  used.  It can currently only be used in MultiSpecies = 1
	  (i.e. no molecular H support).  The following values are used:
	  (1) - Haardt &amp; Madau spectrum with q_alpha=-1.5; (2) -
	  Haardt &amp; Madau spectrum with q_alpha = -1.8; (3) - reserved
	  for experimentation; (4) - H&amp;M spectrum (q_alpha=-1.5)
	  supplemented with an X-ray Compton heating background from Madau
	  &amp; Efstathiou (see astro-ph/9902080); (9) - a constant
	  molecular H2 photo-dissociation rate; (10) - internally computed
	  radiation field using the algorithm of Cen &amp; Ostriker; (11)
	  - same as previous, but with very, very simple optical shielding
	  fudge.  [v1.3 only] Default: 0</p></li>

      <li><p><b class="external">RadiationFieldLevelRecompute</b> (external) - This
	  integer parameter is used only if the previous parameter is set
	  to 10 or 11.  It controls how often (i.e. the level at which)
	  the internal radiation field is recomputed.  [v1.3 only]
	  Default: 0</p></li>

      <li><p> <b class="external">RadiativeCooling</b> (external) - This flag (1 - on, 0 -
	  off) controls whether or not a radiative cooling module is
	  called for each grid.  There are currently two possibilities,
	  controlled by the value of another flag.  If the MultiSpecies
	  flag is off, then equilibrium cooling is assumed, and a file
	  called <tt>cool_rates.in</tt> is read to set a cooling curve.
	  This file consists of a set of temperature and the associated
	  cgs cooling rate; a sample compute with a metallicity Z=0.3
	  Raymond-Smith code is provided in
	  <tt>amr_mpi/exe/cool_rates.in</tt>.  If the Multispecies flag is
	  on, then the cooling rate is computed directly by the species
	  abundances.  This routine (which uses a backward differenced
	  multi-step algorithm) was plundered from the Hercules code
	  written by Peter Anninos and Yu Zhang, featuring rates from Tom
	  Abel.  Default: 0</p></li>

      <li><p><b class="external">RedshiftDumpName</b> (external) - The base file name used
	  for redshift-based outputs (this can be overridden by the
	  CosmologyOutputRedshiftName parameter).  Normally a four digit
	  identification number is appended to the end of this name,
	  starting from 0000 and incrementing by one for every
	  output. This can be over-ridden by including four consecutive
	  R's in the name (e.g.  RedshiftRRRR) in which case the an
	  identification number will not be appended but the four R's will
	  be converted to a redshift with an implied decimal point in the
	  middle (i.e. z=1.24 becomes 0124).  Default:
	  <i>RedshiftOutput</i></p></li>

      <li><p><b class="external">RefineBy</b> (external) - This is the refinement factor
	  between a grid and it's subgrid.  For cosmology simulations, I
	  have found the number 2 to be most useful.  Default: 4</p></li>

      <li><p><b class="external">RefineByJeansLengthSafetyFactor</b> (external) - If the
	  Jeans length refinement criteria (see CellFlaggingMethod) is
	  being used, then this parameter specifies the number of cells
	  which must cover one Jeans length. [v1.3 only] Default: 4</p></li>

      <li><p><b class="external">RefineRefineLeftEdge, RefineRegionRightEdge</b>  @@@@
	  (external) - These two parameters control the region in which
	  refinement is permitted.  Each is a vector of floats (of length
	  given by the problem rank) and they specify the two corners of a
	  volume.  Default: set equal to DomainLeftEdge and
	  DomainRightEdge.</p></li>

      <li><p><b class="reserved">RestartDumpNumber</b> - Reserved for future use.</p></li>

      <li><p><b class="reserved">RestartDumpName </b>- Reserved for future use.</p></li>

      <li><p><b class="external">S2ParticleSize</b> (external) - This is the gravitational
	  softening radius, in cell widths, in terms of the S2 particle
	  described by Hockney and Eastwood in their book Computer
	  Simulation Using Particles.  A reasonable value is 3.0. [Ignored
	  in version 1.3 - amr_mpi].  Default: 3.0</p></li>

      <li><p> <b class="external">SelfGravity</b> (external) - This flag (1 - on, 0 - off)
	  indicates if the baryons and particles undergo self-gravity.</p></li>

      <li><p><b class="external">StarEnergyToQuasarUV</b> (external) - The fraction of the
	  rest-mass energy of the stars created which is returned as UV
	  radiation with a quasar spectrum.  Default: 5e-6</p></li>

      <li><p> <b class="external">StarEnergyToStellarUV</b> (external) - The fraction of
	  the rest-mass energy of the stars created which is returned as
	  UV radiation with a young star spectrum.  Default: 3e-6</p></li>

      <li><p><b class="external">StarEnergyToThermalFeedback</b> (external) - The fraction
	  of the rest-mass energy of the stars created which is returned
	  to the gas phase as thermal energy.  Default: 1e-5</p></li>

      <li><p> <b class="external">StarMakerMassEfficiency</b> (external) - The fraction of
	  identified baryonic mass in a cell (Mass x dt/tdyn) that is
	  converted into a star particle.  Default: 1</p></li>

      <li><p> <b class="external">StarMakerMinimumDynamicalTime </b>(external) - When the
	  star formation rate is computed, the rate is proportional to
	  M_baryon * dt/max(t_dyn, t_max) where t_max is this parameter.
	  This effectively sets a limit on the rate of star formation
	  based on the idea that stars have a non-negligible formation and
	  life-time.  The unit is years.  Default: 1e6</p></li>

      <li><p><b class="external">StarMakerMinimumMass</b> (external) - The minimum
	  mass of star particle, in solar masses.  Note however, the star
	  maker algorithm 2 has a "stochastic" star formation algorithm
	  that will, in a pseudo-random fashion, allow star formation even
	  for very low star formation rates.  It attemps to do so
	  (relatively successfully according to tests) in a fashion that
	  conserves the global average star formation rate.  Default: 1e9</p></li>

      <li><p><b class="external">StarMakerOverDensityThreshold</b> (external) - The
	  overdensity threshold (relative to the total mean density, not
	  just the dark matter mean density) before star formation will be
	  considered. Default: 100</p></li>

      <li><p><b class="external">StarMassEjectionFraction</b> (external) - The mass
	  fraction of created stars which is returned to the gas phase.
	  Default: 0.25</p></li>

      <li><p><b class="external">StarMetalYield</b> (external) - The mass fraction of
	  metals produced by each unit mass of stars created (i.e. it is
	  multipled by mstar, not mejected).  Default: 0.02</p></li>

      <li><p><b class="external">StarParticleCreation</b> (external) - If set to 1 or 2,
	  then one of two possible, experimental, star formation
	  algorithms is used.  The algorithms are from Cen &amp; Ostriker
	  (1992) and the implementation is by Chris Loken, Brian O'Shea
	  and GLB.  The second algorithm (2) is recommended.  Defaut: 0</p></li>

      <li><p><b class="external">StarParticleFeedback</b> (external) - If set to 1 or 2,
	  then one of two possible star feedback algorithms is used.  The
	  second (StarParticleFeedback=2) is recommended.  Default: 0</p></li>

      <li><p><b class="external">StaticHierarchy </b>(external) - A flag which indicates
	  if the hierarchy is static (1) or dynamic (0).  In other words,
	  a value of 1 takes the a out of amr.  Default: 1</p></li>

      <li><p><b class="external">StaticRefineRegionLeftEdge[#],
	    StaticRefineRegionRightEdge[#]</b> (external) - These two
	  parameters specify the two corners of a statically refined
	  region (see the previous parameter).  [v1.3 only] Default:
	  none</p></li>

      <li><p><b class="external">StaticRefineRegionLevel[#]</b> (external) - This
	  parameter is used to specify regions of the problem that are to
	  static refined, regardless of other parameters.  This is mostly
	  used as an internal mechanism to keep the initial grid hierarchy
	  in place, but can be specified by the user.  Up to 20 static
	  regions may be defined (this number set in
	  macros_and_parameters.h), and each static region is labelled
	  starting from zero.  For each static refined region, two pieces
	  of information are required: (1) the region (see the next two
	  parameters), and (2) the level at which the refinement is to
	  occurs (0 implies a level 1 region will always exist).  [v1.3
	  only] Default: none</p></li>

      <li><p><b class="reserved">StopCPUTime</b> - Reserved for future use.    </p></li>

      <li><p><b class="external">StopCycle </b>(external) - The cycle (top grid timestep)
	  at which the calculation stops.  A value of zero indicates
	  that this criterion is not be used.  Default: 0</p></li>

      <li><p><b class="external">StopTime</b> (external) - This parameter specifies the
	  time (in code units) when the calculation will halt.  For
	  cosmology simulations, this variable is automatically set by
	  CosmologyFinalRedshift.  No default.</p></li>

      <li><p><b class="internal">TimeLastDataDump</b> (internal) - The code time at which
	  the last time-based output occurred.</p></li>

      <li><p><b class="reserved">TimeLastHistoryDump</b> - Reserved for future use.</p></li>

      <li><p><b class="internal">TimeLastMovieDump</b> (internal) - The code time at which
	  the last movie dump occurred.</p></li>

      <li><p><b class="reserved">TimeLastRestartDump</b> - Reserved for future use.</p></li>

      <li><p><b class="external">tiny_number</b> (external) - A number which is smaller
	  than all physically reasonable numbers.  Used to prevent
	  divergences and divide-by-zero.  Default: 1e-20.</p></li>

      <li><p><b class="external">TopGridDimensions</b> (external) - This is the dimension
	  of the top or root grid.  It should consist of 1, 2 or 3
	  integers seperated by spaces.  For those familiar with the
	  KRONOS or ZEUS method of specifying dimensions, these values do
	  not include ghost or boundary zones.  A dimension cannot be
	  less than 3 zones wide.  Default: none</p></li>

      <li><p><b class="external">TopGridGravityBoundary </b>(external) - A single integer
	  which specified the type of gravitational boundary conditions
	  for the top grid.  Possible values are 0 for periodic and 1 for
	  isolated (for all dimensions).  The isolated boundary conditions
	  have not been tested recently, so caveat emptor.  Default: 0</p></li>

      <li><p><b class="external">TopGridRank</b> (external) - This specified the
	  dimensionality of the root grid and by extension the entire
	  hierarchy.  It should 1,2 or 3.  Default: none</p></li>

      <li><p> <b class="external">UniformGravity</b> (external) - This flag (1 - on, 0 -
	  off) indicates if there is to be a uniform gravitational field.
	  Default: 0</p></li>

      <li><p> <b class="external">UniformGravityConstant</b> (external) - Magnitude (and
	  sign) of the uniform gravitational acceleration.  Default: 1</p></li>

      <li><p> <b class="external">UniformGravityDirection</b> (external) - This integer is
	  the direction of the uniform gravitational field: 0 - along the
	  x axis, 1 - y axis, 2 - z axis.  Default: 0</p></li>

      <li><p><b class="external">UseMinimumPressureSupport</b> (external) - When radiative
	  cooling is turned on, and objects are allowed to collapse to
	  very small sizes (i.e.  a few cells), and they are evolved for
	  many, many dynamical times, then unfortunate things
	  happen. Primarily, there is some spurious angular momentum
	  generation, and possible some resulting momentum
	  non-conservation. To alleviate this problem, a very simple fudge
	  was introduced: if this flag is turned on, then a minimum
	  temperature is applied to grids with level ==
	  MaximumRefinementLevel.  This minimum temperature is that
	  required to make each cell Jeans stable multiplied by the
	  parameter below.  If you use this, it is advisable to also set
	  the gravitational smoothing length in the form of
	  MaximumGravityRefineLevel to 2 or 3 less than
	  MaximumRefinementLevel. [v1.3 only] Default: 0</p></li>

      <li><p><b class="external">ZEUSQuadraticArtificialViscosity</b> (external) - This is
	  the quadratic artificial viscosity parameter C2 of Stone &amp;
	  Norman, and corresponds (roughly) to the number of zones over
	  which a shock is spread.  Default: 2.0</p></li>

      <li><p><b class="external">ZEUSLinearArtificialViscosity</b> (external) - This is
	  the linear artificial viscosity parameter C1 of Stone &amp;
	  Norman.  Default: 0.0</p></li>
    </ul>

    <hr>
    <address><a href="mailto:jbordner@cosmos.ucsd.edu?subject=ENZO:%20Website%20feedback">Webmaster</a></address>
    <!-- Created: Sat Mar 16 12:48:22 PST 2002 -->
    <!-- hhmts start -->
Last modified: Wed Aug 18 21:33:10 PDT 2004
<!-- hhmts end -->
  </body>
</html>
